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(57) Abstract: The invention relates to a method characterised 
in that an existent working model, as may be provided by an ex- 
pert, may be improved with the actual status of the user within 
the task thereof, the actions permitting a change of status for 
the user are described and the interaction to be carried out with 
the user to manage an event for an event arising for a status 
of the user are described. The list of conditions necessary to 
start the interaction are advantageously added for each interac- 
tion procedure and, after each interaction procedure, the values 
which said interaction, according to the result of said interac- 
tion, should provide are added and which also should be pro- 
vided to the user by return. 

(57) Abrege : Le procede conforme a l'invention est caracte- 
rise en ce qu'a partir d'un modele de tache existant, qui peut 
etre fourni par un expert, on l'augmente avec l'etat courant de 
l'utilisateur dans sa tache, on decrit les evenements permettant 
un changement d'etat de l'utilisateur, on decrit pour un evene- 
ment survenu lors d'un etat de l'utilisateur l'interaction a effec- 
tuer avec l'utilisateur pour gerer cet evenement. De facon avan- 
tageuse, on ajoute avant chaque procedure d'interaction la liste 
des contraintes necessaires pour declencher l'interaction, et on 
ajoute apres chaque procedure d'interaction les valeurs que doit 
fournir cette interaction selon le resultat de l'interaction et qui 
doivent etre presentees a l'utilisateur en retour. 


WO 2005/071536 A2 I II III l« 


(81) Etats designes ( sauf indication contraire, pour tout tit re de 
protection nationale disponible) : AE, AG, AL, AM, AT, 
AU, AZ, BA, BB, BG, BR, BW, BY, BZ, CA, CH, CN, CO, 
CR, CU, CZ, DE, DK, DM, DZ, EC, EE, EG, ES, FI, GB, 
GD, GE, GH, GM, HR, HU, ID, IL, IN, IS, JP, KE, KG, 
KP, KR, KZ, LC, LK, LR, LS, LT, LU, LV, MA, MD, MG, 
MK, MN, MW, MX, MZ, NA, NT, NO, NZ, OM, PG, PH, 
PL, PT, RO, RU, SC, SD, SE, SG, SK, SL, S Y, TJ, TM, TN, 
TR, TT, TZ, UA, UG, US, UZ, VC, VN, YU, ZA, ZM, ZW. 

(84) Etats designes (sauf indication contraire, pour tout titre 
de protection regionale disponible) : ARIPO (BW, GH, 
GM, KE, LS, MW, MZ, NA, SD, SL, SZ, TZ, UG, ZM, 
ZW), eurasien (AM, AZ, BY, KG, KZ, MD, RU, TJ, TM), 


europeen (AT, BE, BG, CH, CY, CZ, DE, DK, EE, ES, FI, 
FR, GB, GR, HU, IE, IS, IT, LT, LU, MC, NL, PL, PT, RO, 
SE, SI, SK, TR), OAPI (BF, BJ, CF, CG, CI, CM, GA, GN, 
GQ, GW, ML, MR, NE, SN, TD, TG). 

Publiee : 

— sans rapport de recherche international, sera republiee 
des reception de ce rapport 

En ce qui conceme les codes a deux lettres et autres abrevia- 
tions, se referer aux "Notes explicatives relatives aux codes et 
abreviations" figurant au debut de chaque numero ordinaire de 
la Gazette du PCT. 


WO 2005/071536 


1 


PCT/EP2004/053527 


Procede d 5 augmentation d'un modele de tache pour permettre la 
gestion de Interaction homme-machine 

La prSsente invention se rapporte a un procSde d'augmentation d'un modele 
de tache pour permettre la gestion de l'interaction homme-machine. 

Dans les systemes actuels disposant d'une interface avec un humain, le 
module de la tache de Putilisateur est enfoui au sein de l'interface. La tache que 
5 l'utilisateur doit effectuer n'est pas explicitement definie, mais se retrouve 
implicitement dans la conception de l'interface. Les concepteurs d'interfaces 
definissent, selon les specifications, les enchaiaements plus ou moins stricts qui sont 
autorisSs a l'utilisateur. Ces enchancements definissent implicitement son module de 
tache. 

10 Cette absence de definition explicite du module de tache d'un utilisateur a 

pour consequence une forte staticite de la tache de l'utilisateur. Dans le cas ou la 
mission de l'utilisateur change ou si l'interface doit Stre dSployee pour une classe 
d'utilisateurs ayant une mission partiellement differente, des modifications sont 
necessaires sur l'interface. Certaines interfaces sont conges en prenant en compte 

15 cette optique de modifications et peuvent etre configures pour §tre adaptees a une 
tache differente. Cette pratique impose une forte charge de travail pour concevoir une 
interfoee suffisamment ouverte pour permettre diff&rentes configurations. De plus, la 
configuration de l'interface pour une nouvelle tache reste complexe dans la mesure 
ou la configuration necessite le travail conjoint d'un expert du domaine pour 

20 specifier la nouvelle tache et d'un concepteur d'interface. Cette pratique, deja 
relativement coftteuse, devient particulidrement difficile k mettre en place si la tache 
de l'utilisateur est susceptible d'evoluer au cours d'une session, ce qui oblige a 
modifier l'application renfermant le moddle de tache. 

La presente invention a pour objet un procede d'augmentation d'un modele 

25 de tache permettant la gestion en temps reel de l'interaction homme-machine sans 
avoir a modifier l'application liee k ce modele de tache, en particulier lorsque l'on 
fait evoluer les modules de taches, l'interaction pouvant §tre multi-utilisateurs. 
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Le procSde conforme a l'invention est caractSrise en ce qu'a partir d'un 
modele de tache existant, on l'augmente avec l'etat courant de Futilisateur dans sa 
tache, on decrit les evenements permettant un changement d'etat de l'utilisateur, et 
on decrit pour un evenement survenu lors d'un etat de l'utilisateur l'interaction a 
5 effectuer avec l'utilisateur pour gerer cet 6venement. De fa$on avantageuse, on 
ajoute avant chaque procedure d'interaction la liste des contraintes necessaires pour 
dSclencher l'interaction, et, egalement de faqon avantageuse, on ajoute aprds chaque 
procedure d'interaction les valeurs que doit fournir cette interaction selon le resultat 
de l'interaction et qui doivent Stre presentees a l'utilisateur en retour. 

La pr6sente invention sera mieux comprise & la lecture de la description 
d&aillee d'un mode de realisation, pris a litre d'exemple non limitatif et illustrS par 
le dessin annexe, sur lequel : 

- la figure 1 est un diagramme simplifie explicitant diff&rentes etapes 
de la mise en oeuvre du procede de l'invention dans une application, 

- la figure 2 est un bloc-diagramme simplifie de I'architecture d'un 
gestionnaire de taches conforme k l'invention, et 

- la figure 3 est un diagramme simplifie du deroulement des taches du 
gestionnaire de taches de l'invention. 

Le procedS de l'invention consiste essentiellement a dScharger les 
concepteurs d'interfaces homme-machine de la question de la tache de l'utilisateur. 
Les concepteurs n'auront qu'a se concentrer sur les fonctionnalites d'interface dont 
l'utilisateur a besoin sans se prSoccuper des enchancements qu'il aura a realiser pour 
mener a bien sa tache. 

L'invention part d'un module de tache externe existant et l'augmente de telle 
sorte qu'il puisse Stre utilise pour piloter l'interaction. De plus, ce module sert de 
base de specification aux concepteurs d'interfaces pour connaStre les services 
necessaires aux utilisateurs. 

Enfin, ce moddle de tache externe est utilise par un gestionnaire de taches qui 
est capable de prendre en compte en temps reel tout changement dans le module de 
tache lors de l'execution de la tache. 
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L'invention decrite ici precise et met en oeuvre des reponses aux problemes 
poses par le besoin de developpement et de configuration des interfaces suite a des 
modifications de tache de l'utilisateur ou suite a une demande de d6ploiement a 
Tintention d'autres utilisateurs avec une tache differente. En ce sens, cette invention 
5 a des repercussions sur toutes les categories de systemes ou l'humain tient une place 
prSponderante, et ceci dans toutes sortes de domaines duplication, comme par 
exemple : 

• La defense : syst&tnes d'armes, de commandement, de simulation et 
d'entrainement ; 

10 • Les transports : syst&nes de pilotage, de supervision, de reservation ; 

• Les communications : telephonie, radio, television, Internet ; 

• La vie quotidienne : systSmes 61ectromenagers, v£hicules individuels, 
informatique domestique omnipr6sente et diffuse (« ubiquitous computing » 
en anglais) ; 

15 • Les services : systemes bancaires, commerce electronique, assistance 
technique ; 

• La sante : systemes hospitaliers, secours operationnel ; 

• Etc. 

La presente invention propose un nouveau proc6d6 pour augmenter un 
20 module de tache existant afin de permettre une gestion en temps r6el de Finteraction 
pilotee par le modele de tache. Son principe fondamental est d'utiliser un moddle 
existant de tache des utilisateurs et de l'augmenter avec les connaissances necessaires 
pour le pilotage de l'interaction. Plus precisement, le module de tache d'un operateur 
comporte, en plus de l'enchainement des taches a realiser, les 6venements pouvant 
25 survenir, la description des interactions a effectuer, les conditions de declenchement 
necessaires et les informations a fournir en retour. Ce module de tache augmente 
permet de piloter l'interaction en temps reel grace a un composant suppl&nentaire, le 
gestionnaire de taches, qui fournit les services d'accds au modele de tache. Le 
module de tache en tant que connaissance externe a l'interaction est dynamique. De 
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ce fait, le gestionnaire de tfiches autorise une evolution du module de tache au cours 
du temps avec repercussion en temps reel sur rinteraction avec l'utilisateur. 

Habituellement, un moddle de tache decrit les differentes etapes qu'un 
utilisateur peut ou doit effectuer pour mener a bien sa tache globale. La tache de 
5 l'utilisateur doit §tre decrite sous forme d'un enchainement alternatif, sequentiel ou 
en paraltele de sous-taches avec une mention particuliere pour 1'etat initiaL Selon 
1'invention, les sous-taches effectuees par l'utilisateur correspondent k autant d'6tats 
dans lesquels se trouve l'utilisateur (en etat d'effectuer une sous-tSche). 

La premiere etape du procedd de l'invention part d'un module de tache 

10 existant fourni par un expert, et elle consiste a augmenter cette representation avec 
l'6tat courant de l'utilisateur dans sa tache. Cette connaissance supplementaire 
permet de suivre l'utilisateur dans sa tache. 

La deuxieme etape consiste a decrire les evenements permettant un 
changement d'etat de l'utilisateur (fin d'une sous-tache pour en debuter une autre). 

15 Ces evenements peuvent Stre des evenements k l'initiative de l'utilisateur ou des 
evenements externes survenus dans l'environnement L'environnement est defini ici 
comme tout excepte l'utilisateur : la ou les applications, les autres utilisateurs, des 
capteurs,... Ce proc6de ajoute ainsi sur chaque transition entre deux 6tats de 
l'utilisateur la liste d'un ou de plusieurs evenements declenchant le changement 

20 d'etat. Les evenements inscrits dans le module de tache peuvent 6tre de granularity 
plus ou moins fine selon les besoins. Selon une caracteristique avantageuse de 
l'invention, on utilise un module externe qui fournit les evenements (on 1' « utilise » 
dans le sens d'un client utilisant un fournisseur). Ce module est n'importe quelle 
sorte d'interface homme-machine (informatique ou non). n peut, par exemple, s'agir 

25 d'un capteur de poids sur un sidge qui fournit un evenement « assis ». Ce module 
fournit une abstraction des actions de l'utilisateur sous forme d' evenements de haut 
niveau. Cette abstraction permet d'utiliser le meme evenement dans le module de 
tache quelle que soit la maniSre dont l'utilisateur a interagi avec le systeme 
(vocalement, graphiquement, par geste,...)- D est egalement possible d'utiliser des 

30 evenements de bas niveau dans le modele de tache. La distinction entre evenements 
de bas niveau et de haut niveau 6tant faite ici dans le sens ou celui de haut niveau est 
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la g6neralis ation d'un ou plusieurs evenements de bas niveau. Par exemple, il peut 
§tre avantageux, dans un modele de tache, de declencher une action sur l'evenement 
« Select » (de haut niveau), que ce soit une selection a la souris, avec un joystick ou 
une designation par geste. D'un autre cdte, il peut etre avantageux de pouvoir definir 
5 trois actions diff<§rentes pour ces trois ev&iements (bas niveau). On peut utiliser une 
interface (quelle qu'elle soit) qui puisse renvoyer un evenement generique (Select) 
dans certains contextes et des 6v6nements specifiques dans d'autres contextes. 

La troisi^me etape consiste k decrire, pour un evenement survenu lors d'un 
etat de l'utilisateur, l'interaction a effectuer avec l'utilisateur pour g6rer cet 

10 evenement. L'interaction est d&finie comme une procedure a derouler (interrogation 
d'applications, calcul d'une valeur, verification d'une donn6e,...). En fait, le modele 
de tSche peut faire reference ^plusieurs applications differentes. Ainsi, l'utilisateur a 
une seule et mdme interface, et ce sont alors les procedures d'interaction qui se 
chargent d'acceder aux applications necessaires. Chaque procedure d'interaction doit 

15 fournir un resultat permettant de decider du prochain etat de l'utilisateur. Pour 
chaque resultat possible de la procedure d'interaction, une transition Stiquetee par le 
resultat permet d'atteindre un nouvel etat de l'utilisateur. Par exemple., dans le cas ou 
l'utilisateur est dans l'etat « deconnecte » et qu'il declenche un evenement de 
« connexion » 3 la procedure d'interaction, apres avoir interroge l'application, fournit 

20 une reponse polaire (oui/non). Si la reponse est positive, l'utilisateur accdde a l'etat 
« connecte », sinon il reste dans l'etat « deconnecte », comme decrit dans le modele 
de tache augmente. 

La quatridme etape consiste k ajouter avant chaque procedure d'interaction la 
liste des contraintes necessaires pour declencher l'interaction. Ces contraintes 
25 peuvent etre la fourniture de paramdtres, la verification d'une valeur,... (Dans 
Fexemple precedent, la contrainte pourrait etre la fourniture d'un identifiant et d'un 
mot de passe.) 

La dernidre etape consiste a ajouter aprSs chaque procedure d'interaction les 
valeurs que doit fournir cette interaction selon le resultat de l'interaction et qui 
30 doivent etre presentees k l'utilisateur en retour. (Dans l'exemple precedent, la sortie 
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de la procedure d'interaction permettant la connexion pourrait §tre le «mot du 
jour ».) 

Le proc6de de 1 'invention identifie clairement les actions k effectuer par 
l'utilisateur ainsi que leur sequencement, les evenements pouvant §tre declenches ou 
5 perfus par l'utilisateur ainsi que les interactions (au sens de la t&che) avec 
l'environnement 

Un modele de tSche ainsi augmente peut se presenter sous forme de graphe. 

Le formalisme utilise pour ce graphe doit offrir une puissance d'expression suffisante 

pour exprimer les etats (sous-tfiches) de l'utilisateur, les contraintes a verifier pour 
10 l'execution d'une procedure d' interaction, les valeurs fournies par une procedure 

d'interaction, les evenements pouvant survenir et la maniere de les prendre en 

compte. H est aussi necessaire que le formalisme permette la representation de 

1'interruption de tache, la reprise aprds interruption, etc. 

La gestion en temps reel d'un tel module de t&che est effectuee par le 
15 gestionnaire de taches encapsulant l'acc&s aux modeles de t§ches. II se comporte 

comme un fournisseur de services qui seront decrits ci-aprds. Le gestionnaire est & 

meme de gerer plusieurs modeles de taches differents et plusieurs utilisateurs en 

parallele. La multiplicity des modules de taches geres par un meme gestionnaire 

permet la collaboration entre plusieurs utilisateurs ayant des taches potentiellement 
20 chfferentes. Le gestionnaire de taches prend en compte l'evolutivite dans le temps 

d'un moddle de tSche en offrant des services d'acces pour des composants qui 

pourraient alterer les modules. 

Afin de faciliter l'Scriture et la relecture de ces modules de tSches, des outils 

de saisie et de relecture sont mis en oeuvre. Ces outils permettent & un expert de 
25 pouvoir facilement exprimer ou verifier la tache d'un ou de plusieurs utilisateurs, de 

preciser les differentes synchronisations dans le cas d'un travail collaboratif et de 

verifier la coherence des moddles. 

Les principaux avantages du procede de l'invention sont les suivants. 

D'abord, la presente invention consiste a augmenter le module de t&che avec de 
30 nouvelles connaissances, Ce module de t&che augmente permet de piloter 

Pinteraction homme-machine en temps reel. Les concepteurs des modules gerant 
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l'interaction avec l'utilisateur n'ont plus a se soucier de la manidre de gerer 
l'interaction, ces informations etant localisees au sein du modele de t§che et 
accessibles via le gestionnaire de taches. 

L'invention presente aussi 1' avantage de memoriser le contexte de tache d'un 
5 utilisateur et est ainsi k meme d'aider a maintenir une coherence dans sa mission, que 
ce soit en cas d'interruption volontaire (fin de session,...) ou non volontaire (panne 
impliquant une interruption ou un changement de poste de travail, . . .). 

Un autre avantage est la generation automatique d'interfaces. Le modele de 
tSche decrivant l'interaction necessaire k l'utilisateur selon le point d'avancement de 
10 sa t&che, il devient possible de mettre en place un systdme de generation automatique 
d'interfaces au vol. Le moddle de tache fournit les informations necessaires sous 
forme d'Stats pouvant Stre atteints et d'evdnements ddclenchables selon les 
eontraintes, en fonction de l'etat courant de l'utilisateur. 

Un autre avantage repose sur la modification en temps reel du module de 
15 tache. L'interaction avec Futilisateur peut Stre modifide en temps reel dans le cas oix 
des contraintes externes l'exigent, comme par exemple une modification des niveaux 
de s6curit6. L'interface de l'utilisateur peut alors Stre modifiee en temps rdel. 

L'invention decrite ici, en plus des avantages cites precedemment, ouvre la 
voie k de nouvelles possibilites. Parmi ces possibilites on peut citer Papprentissage 
20 par un module exteme. Ce module doit recevoir tous les changements d'etat de 
l'utilisateur en temps reel et doit §tre capable d'apprendre son comportement 
typique. L'apprentissage peut se faire en temps reel ou en differe. a partir d'un 
moddle de tache (ce que devrait faire l'utilisateur) de l'activite d'un utilisateur (ce 
qu'il fait reellement), pouvant ainsi permettre d'influer sur son moddle de t§che en 
25 temps rdel. Le module d'apprentissage est alors a mSme d'alterer le moddle de t&che 
pour simplifier la tSche, pour optimiser son deroulement ou pour s 'adapter k la 
manidre de travailler de chaque utilisateur. Le procede permet la prise en compte en 
temps reel de ces alterations. 

Un autre avantage est de permettre la mise en place aisSe de techniques de 
30 planification des taches de l'utilisateur. Cette plamfication permet de prevoir ses 
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actions et d'anticiper ses demandes (chargement par anticipation de modules 
logiciels, t^lechargement anticip6 de donnees longues a obtenir,. . 

Selon une autre caracteristique de Finvention, on applique la separation entre 
Fapplication et l'interface homme-machine decrite dans la demande de brevet 
5 fran§ais 02 12012. L'interface est alors developpee sous forme de services 
d'interaction selon les specifications du module de tache. L'interface ne comporte 
alors plus le modele de tSche enfoui de Futilisateur. Avant, l'interface definissait que 
telle fen6tre presentait telles donnees et permettait Facc&s & telles autres fen€tres 
(etats). Desormais, selon Finvention, les developpeurs d'interfaces connaissent les 

10 fenStres a developper en consultant le module de tache. Pour chaque etat, il faut une 
fenetre permettant d'afficher les informations a presenter (diode precedant Fetat, en 
reference a la figure 1, decrite ci-dessous) et de proposer des fonctionnalites pour 
d£clencher les evemements de sortie (des boutons, par exemple). Ainsi, le 
developpeur d'interfaces ne developpe plus l'interface complete, mais une liste de 

15 services d'interface pour les etats. Pour l'adaptation automatique de l'interfece en 
temps reel, on peut envisager des systemes ou, selon l'Stat dans lequel va arriver 
Futilisateur, connaissant les donnees a lui presenter et les fonctions necessaires 
(boutons), on choisit le meilleur service d'interface dans une liste. II peut done y 
avoir trois interfaces permettant de presenter la liste des vols et d'acceder a la suite 

20 du module de tache. La premiere vocale, la seconde pour un grand ecran et la 
troisidme pour un PDA (assistant personnel). Le gestionnaire de tdches fournit la 
coimaissance definissant les besoins en termes d'interface (presenter une liste de vol 
et les evenements declenchables), et e'est un autre module qui, selon le contexte de 
Futilisateur, appelle tel ou tel service d'interface. Cette caracteristique est trds 

25 avantageuse dans la mesure ou plusieurs services d'interface peuvent exister en 
paralldle et etre choisis selon le contexte. Cette adaptation permet a Futilisateur 
d'effectuer une mdme tSche sur des terminaux differents, avec des modalites 
differentes,... 

De plus, le choix des procedures d'interaction etant defini au sein du moddle 
30 de tSche, l'approche du developpement de l'interface du point de vue des services la 
rend independante de Fapplication sous-jacente. Un changement d'application 
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continuant a offirir des services similaires, impliquera seulement une mise k jour des 
procedures d'interaction du module de tache sans alteration necessaire sur Finterface. 

En plus des adaptations pr6cedentes ? le developpement d'une interface sous 
forme de services grace au module de tache permet de faire varier le modele de tache 
5 selon Futilisateur sans impliquer de developpement suppiementaire au niveau de 
Finterface. 

Le modele de tache augmente devient aussi la specification permettant la 
conception et le developpement des interfaces et permet de federer les developpeurs 
de ^application avec les developpeurs d'interfaces. Pour les concepteurs d'interfaces, 

10 ce module de tache decrit les interactions qui seront necessaires k Futilisateur pour 
effectuer sa tache. Ce modele, en tant que specification d'interaction, garantit une 
interface repondant aux besoins des utilisateurs. De plus, le modele de tache definit 
les procedures d'interaction (generalement des ensembles d'appels de services 
applicatifs) a dedencher lors d'une demande de changement d'etat de la part de 

15 Futilisateur. Ceci permet aux developpeurs d' applications de connaStre la liste des 
services necessaires a Futilisateur. Ce formalisme permet aux concepteurs 
d'interface de s'abstraire de tous les services applicatifs, car la description des 
services applicatifs a dedencher est precisee dans le modele de tache. 

Une realisation possible de la pr£sente invention est Faugmentation du 

20 module de tache d'un utilisateur. La connaissance fournie en entree du precede est un 
module de tache d'un utilisateur. Ce procede a permis Faugmentation du modele de 
tache en collaboration avec les experts afin d'obtenir une version etendue dont un 
exemple partiel est donne ci-aprds. 

Afin de gerer au mieux ce modele de tache, un mode de realisation consiste k 

25 mettre en place un « gestionnaire de taches ». Ce dernier a pour objectif de fournir 
les services d'acces k la tache pour les autres modules logiciels qui en ont besoin. Le 
modele de tache repose, dans le present exemple, sur le format XML, aise a 
percevoir pour les experts qui devront Fexprimer et pour les concepteurs d'interfaces 
qui devront Futiliser. Le gestionnaire de tache fournit Faeces aplusieurs modeies de 

30 taches differents pour plusieurs utilisateurs, en paralieie et en temps reel. 
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Le module de tache decrit les differents 6tats de l'utilisateur au sein de sa 
t£che et d6crit les actions qu'il peut entreprendre pour changer d'etat Ce formalisme 
definit l'etat de depart d'un utilisateur qui debute sa tSche. Pour chacun des etats de 
l'utilisateur., un certain nombre d'actions possibles (potentiellement une seule) 
5 peuvent le conduire dans un nouvel etat en d6clenchant une procedure d'interaction 
(generalement un appel a un ou plusieurs services applicatifs). Les transitions 
pr£sentes dans ce formalisme peuvent comporter des contraintes. La necessity de 
disposer d'une donnee particulfere pour autoriser le dSclenchement d'une action est 
une forme de contrainte. Les modules de taches de plusieurs utilisateurs peuvent §tre 
10 lies entre eux de maniere k pouvoir prendre en compte les probldmes de travail 
collaboratif. 

Selon le formalisme de Tinvention, les etats de Futilisateur sont decrits par 
des ovales, les procedures d'interaction par des losanges et les paramdtres 
necessaires pour declencher une procedure par des diodes. Les informations fournies 
15 par une procedure d'interaction sont aussi d6crites sous forme de diodes et indiquent 
aux developpeurs d'interfaces les informations resultant de la pr6c6dente procedure 
d'interaction qu'il faudra presenter a l'utilisateur. 

Dans le cas ou il existe une hi&rarchie des classes d'utilisateurs en termes de 
tache ou certains utilisateurs ne disposent que d'une t§che partielle a realiser par 
20 rapport k d'autres ayant la tache complete, le moddle de tache permet de specifier la 
hi6rarchie de modeles de tfiches afin de faciliter la specialisation ou la generalisation 
des modules. 

Le gestionnaire de taches de Tinvention se presente sous forme d'un module 
externe et temps reel fournissant l'accds aux modules de tache dont il a la charge. II 
25 fournit tous les services d'acc&s necessaires, comme l'initialisation d'un module de 
tache lors de la connexion d'un nouvel utilisateur, l'identification du moddle de tache 
selon la classe de l'utilisateur, la fourniture de la prochaine procedure d'interaction 
en fonction d'un evenement, la fourniture du prochain etat en fonction du resultat 
d'une procedure d'interaction. Ce module est capable de gerer en parallele plusieurs 
utilisateurs en memorisant le contexte de chacun (son processus de fonctionnement 
est decrit en reference a la figure 3). La securite de fonctionnement de la gestion de 
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tache doit dtre assuree, par exemple avec une verification des actions de Futilisateur 
vis-a-vis de sa tache. Le gestionnaire de taches fournit aussi les services d'acces en 
ecriture aux differents modules de taches avec sauvegarde des modeles alteres. Le 
gestionnaire de taches peut utiliser un module de stockage externe afin d'acceder aux 
5 moddles de taches des utilisateurs. 

On a repr6sente en figure 1 cinq Stapes principales du procede 
d'augmentation de tache, conformement k Finvention. Une fleche pleine correspond 
k une reponse positive et une fldche pointillSe correspond a une reponse negative. 
Dans cette figure, la premiere etape El represente le module de tache initial. On y a 
10 figure dans des ellipses deux etats successifs de l'utilisateur, a savoir "Disconnected" 
(deconnectS, ou plus precisement, non encore connecte a un appareil, par exemple un 
microordinateur), et "Connected" (connecte a cet appareil). On parle d'etat initial 
lorsqu'il s'agit du premier etat dans lequel se trouve un utilisateur qui commence sa 
tache. 

15 A Petape suivante E2, on ajoute Fetat courant de Futilisateur k l'aide d' une 

« balise » stockee par le gestionnaire de taches . Cet etat courant se presente, par 
exemple, comme une variable ecj, (i pouvant prendre les valeurs lan pour n etats 
possibles de Futilisateur). 

Le proc6de de Tinvention consiste ensuite (etape E3) k introduire entre ces 

20 deux etats la description d'un evenement (figuree dans un rectangle), qui est ici 
"Connect" (demande de connexion), et qui permet de faire passer Tutilisateur du 
premier etat vers le deuxidme. Inversement, on introduit la description d'un autre 
evenement, "Disconnect", qui permet de faire passer l'utilisateur du deuxiSme vers le 
premier 6tat 

25 A FStape suivante E4, on ajoute les procedures d'interaction (figurees 

chacune dans un losange. Ces procedures sont la connexion de l'utilisateur a la 
machine (« connect ») et la deconnexion (« disconnect »). 

Aprds la description d'evenement "Connect", on introduit (etape E5) les 
paramStres regissant le declenchement de Taction prevue (figures par une diode), 

30 c'est-a-dire le declenchement du processus de connexion de l'utilisateur a la machine. 
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Dans le cas present, il y a deux tels parametres, "User ID" (identite de l'utilisateur) et 
"Password" (mot de passe), la description de la procedure d'interaction avec 
l'utilisateur, et dans le cas present, il s'agit simplement de la procedure de connexion 
"Connect" citee ci-dessus. On remarquera que pour faire passer l'utilisateur du 
5 deuxidme vers le premier 6tat, il n f y a pas besoin de faire intervener de parametres, la 
deconnexion devant se faire inconditionnellement. Lors de cette procedure de 
connexion, il y a, par exemple, verification de l'exactitude des parametres fournis par 
l'utilisateur a l'aide d f un clavier, dune carte ^identification a circuit integre (dite 
"carte k puce" ou "smart card" en anglais,...)- Le module de t&che decrit que la 

10 procedure « Connect » doit §tre appelee lors de ce changement d'etat. Cette 
procedure est externe au modele de tache, et seule une reference (ici son nom) 
permet de la retrouver. Le gestionnaire de taches, suite a Pevenement « connect » 
dans l'<§tat «deconnecte» precise qu'il faut appeler la procedure « Connect ». 
Ensuite, c'est au module qui interroge le gestionnaire de t&ches d'appeler cette 

15 procedure. Ainsi, le modele de tache n'a aucune id6e du contenu de cette procedure. 
Bien entendu, le bon sens voudrait, dans le cas present qu'il y ait verification du mot 
d'identification et du mot de passe de l'utilisateur. Si les parametres ainsi verifies 
sont incorrects, done refuses ("connection refused"), le gestionnaire ramSne 
l'utilisateur dans l'Stat initial ("dSconnecte", par le trajet en traits interrompus). Le 

20 gestionnaire ne fait que repondre a des requStes et memoriser l'etat de l'utilisateur. II 
memorise done que le nouvel etat est « deconnectS » et rend cette reponse a son 
appelant. Dans l'affirmative, le gestionnaire renvoie le profil fourni par la procedure 
d'interaction (profil qui peut par exemple figurer sur ladite carte d'identification) 
pour dSclencher Taction de connexion et il memorise que l'utilisateur est desormais 

25 dans l'etat connecte et repond cela k son appelant Dans le present exemple, ces 
paramdtres sont ceux d'une liste de vol d'un utilisateur d'une compagnie aerienne 
("Flight list"), et la connexion est etablie avec ce profil d'utilisateur, qui passe done 
dans le deuxi&me etat. 

La partie de fichier suivante correspond a la traduction de ce schema sous 

30 forme XML. 
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<state id="disconnected"> 
<events> 

<event id="connect"> 

<in_param id="userid" type="javaJang.String" l> 
5 <injparam id=="password" type="java.lang. String" /> 

<interaction_call id="connect" > 

<method id="processing.business.haiidler.ConBect" l> 
<next_states> 

<positive> 

10 <out_param id="flightjist" 

type="busiiiess.FlightList" /> 

<next_state id="connected" /> 
</positive> 
<negative> 

15 <out_param id="connection_refused" 

type="java.lang. String" /> 

<next_state id="disconnected" /> 
<ynegative> 
</next__states> 
20 </interactioncall> 
</event> 
</events> 
</state> 


On a represents en figure 2 le bloc-diagramme des principaies fonctions 
mises en oeuvre par le procede de Invention. Comme precise ci~dessus, Invention 
part d ! un moddle de tache augmente (1) qui communique bi-directionnellement avec 
le gestionnaire de t&ches (2). Ce dernier coopSre avec des services (3) de 
30 Implication. Le gestionnaire de f&ches fournit des services aux modules qui en ont 
besoin.Le diagramme de la figure 3 resume le processus de fonctionnement du 
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gestionnaire de taches. Le processus debute par rinitialisation et le positionnement de 
Tetat initial de Futilisateur (4). Cette 6tape est suivie de la demande de la prochaine 
procedure d ! interaction en liaison avec un Svenement du a Putilisateur (5), Cette 
demande dialogue avec la demande du prochain etat de l'utilisateur en fonction du 
5 resultat de la procedure d'interaction (6), qui dialogue de son c6te avec la demande 
de la prochaine procedure d'interaction en fonction d ! un 6v6nement externe (7). 
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REVINDICATIONS 

1. Procede d'augmentation d'un modele de tache pour permettre la 
gestion de r interaction homme-machine., caracterise en ce qu*& partir 
d'un modele de t&che existant, on F augmente avec Fetat courant de 
Putilisateur dans sa tache, on dScrit les ev6nements permettant un 

5 changement d'etat de Tutilisateixr, et on decrit pour un Svenement 

survenu lors d'un 6tat de l'utilisateur Finteraction a effectuer avec 
Putilisateur pour g&rer cet evenement. 

2. Proced6 selon la revendication 1, caracterise en ce que Ton ajoute 
avant chaque procedure d'interaction la liste des contraintes 

10 n6cessaires pour declencher Finteraction. 

3. ProcSde selon la revendication 1 ou 2, caracterise en ce que Ton 
ajoute apres chaque procedure d'interaction les valeurs que doit 
fournir cette interaction selon le resultat de Finteraction et qui 
doivent Stre presentees a Futilisateur en retour. 

15 4. Procede selon Tune des revendications pr6cedentes, caracterise en ce 

que Von utilise un module externe qui fournit une abstraction des 
actions de l'utilisateur sous forme d ! 6venements de haut niveau, 
5. Procede selon la revendication 1 ou 2, caracterise en ce que Ton 
modifie en temps reel le modele de tache. 

20 6. ProcedS selon Tune des revendications 1 a 3, caracterisS en ce que 

Ton modifie Interaction avec l'utilisateur en temps r6eL 
7. Procede selon Tune des revendications prScedentes, caracterise en ce 
qu'un module d'apprentissage realise Fapprentissage a partir de 
Tactivite d ! un utilisateur, selon le module de tSche augmente. 

25 8, Procede selon Tune des revendications precedentes, caracterise en ce 

que les specifications des services d'interface homme-machine sont 
derives du module de t&che augmente. 
9. Procede selon Tune des revendications precedentes, caracterise en ce 
que le module de t&che est fourni par un expert. 
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